FIG. 1 is a schematic diagram illustrating an exemplary service network 100. The service network 100 comprises a multiprotocol label switching (MPLS) service provider backbone network 112 supporting a plurality of individual private network sites 1021-102n (hereinafter collectively referred to as “sites 102”). A subset of these sites 102 forms a virtual private network (VPN). The backbone network 112 comprises a plurality of provider edge (PE) routers 1061-106n (hereinafter collectively referred to as “PE routers 106”) and a plurality of provider core routers 1081-108n (hereinafter collectively referred to as “P routers 108”) for receiving and forwarding data (e.g., received from sites 102). Each of the sites 102 comprises at least one customer edge router 1041-104n (hereinafter collectively referred to as CE routers 104″) that connects the site 102 to the backbone network 112. If at least two of the sites 102 are multicast-enabled, they make up a “multicast domain”.
Each multicast domain has a default multicast distribution tree (MDT) through the backbone network 112 that defines the path used by PE routers 106 to send multicast data and control messages to every other PE router 106 connected to the multicast domain. In some cases, this default MDT may not be the most optimal means of forwarding data. For example, consider a multicast domain comprising sites 1021, 1022 and 1023. If a default MDT were used to send data to a subset of sites 102 in the multicast domain (e.g., from a sender in site 1021 to a receiver in site 1023), the data would also be forwarded to destinations in the multicast domain that are dead ends, i.e., not on the path to the intended receiver (e.g., PE router 1062). This is wasteful, especially for high-bandwidth multicast traffic, and makes the service network 100 very difficult to scale.
One solution to the bandwidth conservation problem is the implementation of individual MDTs for specific multicast groups, referred to as “data MDTs”. A data MDT (e.g., data MDT 110, illustrated as a dashed line) delivers VPN data traffic for a particular multicast group (e.g., comprising sites 1021 and 1023) only to those PE routers 106 that are on the path to receivers of the multicast group. This reduces the amount of multicast traffic on the backbone network 112 and reduces load on some PE routers 106. However, it also increases an amount of VPN-specific state knowledge (e.g., routing information) that must be maintained by the P routers 108, as a separate MDT must be maintained for each multicast source or multicast group. Therefore, the problem of scalability remains.
Thus, there is a need in the art for a method and apparatus for scalable virtual private network multicasting.